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1 Related Applications 

This application claims priority to provisional application no. 60/168,754 filed on December 6, 1999, ti- 
tled, "An E-Commerce Infrastructure for Value Chains" , the contents of which are herein incorporated by 
reference. 

2 Field of the Invention 

The invention relates to a method and system for discovery of trades between parties. In particular, the 
invention is a system which allows buyers to define their preferences and sellers to define their capabilities, 
then determines which trading points maximize the utility of the buyer. The system suggests trades by 
exploiting the flexibilities and tradeoffs encoded by both parties, thus providing win- win trades. A second 
level of optimization ranks the trades with all suppliers, allowing the buyer to rapidly determine the best 
alternatives. The system allows for rich negotiation spaces and supports continuous, discrete, and range or 
interval decision factors. 

3 Background of the Invention 

The present invention relates to methods of automatic exploration and exploitation of the flexibilities pos- 
sessed by negotiating parties to uncover improved win- win agreements. The invention describes computa- 
tionally efficient mechanisms that are applicable whether there are one or many selling parties. The precise 
number and types of negotiating dimensions are irrelevant as long as they are numerical. Thus the present 
invention applies equally to the optimal determination of terms in the purchase of a commodity or an 
arbitrarily complex artifact. 

Electronic markets have proliferated over the last few years with the advent of B2C (business-to-consumer) 
and B2B (business-to-business) electronic commerce. Such market places have yielded significant cost savings 
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by lowering the transaction costs between buyers and sellers. Buyers have also profited through increased 
competition between suppliers. However, electronic markets have hurt suppliers, since the zero- sum negoti- 
ation over price has been at their expense. The present invention describes a tool whereby cost savings for 
both parties are derived from the discovery of win- win trades. Fundamentally, the system works by allowing 
trading parties to describe their desired trade across multiple dimensions and to express their flexibility 
around this ideal trade. Through an algorithmic exploration of their flexibilities, the present invention can 
discover trades that are near the ideal trades of both parties, enabling both to win. 

The adoption of B2B and B2C electronic commerce was facilitated by the migration of catalogues online. 
This familiar method of presentation ameliorated the significant cultural change to electronic trade. For the 
foreseeable future, electronic commerce will be dominated by online catalogs. At present, online catalogues 
are direct translations of their hardcopy counterparts where the attributes of a product are described and a 
price quoted. Inevitably however, online catalogs will become more expressive. Catalog entries will be able 
to represent price breaks for large quantity orders, lot sizes, etc. Thus it is important that any software 
(like the present invention) that uncovers mutually beneficial trading scenarios is able to operate with such 
catalogs. Consequently, in the present invention there is an asymmetry between buyer (usually a human) 
and seller (usually an online catalog). 

One of the reasons catalogs have come to dominate electronic commerce is that the types of goods that 
can be represented in catalogs are simple. Whether the product is pens or paper clips, different vendor's 
offers differ little from each other (a pen is a pen is a pen), and a quick scan of a catalog gives a buyer 
enough information to make an informed purchase. These types of goods are low margin and inexpensive. In 
contrast, the vast amount of purchasing between businesses involves materials which are directly connected 
with business operations - car parts, turbines, etc. Such direct goods are the future of electronic commerce. 
Unlike present-day engines, any truly useful procurement tool must be able to support direct materials with 
complex attributes and complex inter-relationships between its components. 

Electronic commerce offers unprecedented opportunities for more informed decision-making for both 
buyers and sellers. The past few decades have seen the widespread adoption of enterprise resource planning 
(ERP) systems, to the point that now almost every major company has some form of ERP software. ERP 
functions as the digital nervous system of a company, transmitting and logging information between the 
company's many different business functions. ERP software keeps track of inventory, monitors the state 
of purchase orders, signals when a company should reorder direct and indirect materials, and a myriad of 
other functions. Consequently, ERP databases are a rich source of information to optimize a company's 
operations. Yet today this information is rarely used to make more informed buying and selling decisions. 
The present invention can utilize such information sources to optimize a company's interactions with suppliers 
and customers. 
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One important manner in which this optimization can occur is through an analysis of all cost factors. 
Current buying and selling practices often focus on limited goals, e.g., minimize the total purchase price. 
Myopic purchasing strategies often result in higher total cost of ownership when all cost factors relevant to a 
product in its lifetime of use are included. These other cost factors can be significant. Why save the money 
in taking delivery two days late if the receiving docks will be full at that time and an additional shift needs 
to be hired to clear the docks? Why order the cheaper drill bit if it is much more expensive to replace when 
it breaks? The present invention improves trades by minimizing the total cost of ownership of a product, 
yielding significant savings to its users. Many total cost factors are difficult to quantify - e.g. what is the cost 
of dealing with a unionized versus a non-unionized supplier? Consequently, the present invention supports 
qualitative (best guesses and intuition) as well quantitative factors. 

All companies are situated in a supply or value chain. At each step in the chain, a company purchases 
from its suppliers, transforms these inputs, and sells the output to its customers. The termination of the 
supply chain is the sale of the final product to the end consumer. Since the only influx of external capital 
comes from the end consumer, companies have realized that they compete not only as individuals but 
also as entire supply chains. As result, software products have recently become available which attempt 
to streamline the operations of links within the entire supply chain. This software, variously called supply 
chain optimization (SCO) or advanced planning and optimization (APO), operates on the basis of forecasted 
demand at various points within the supply chain. Based on these predictions, plans are generated telling 
companies how much to produce and how to schedule their operations. SCO systems are a valuable source 
of intra-company information - data the present invention capitalizes on. Because SCO software relies on 
forecasted demand, it is only as helpful as the forecast is accurate, and, unfortunately, in many cases demand 
is very difficult to predict. How can the software know that laundry detergent will go on special at grocery 
stores in the Northeast in 7 weeks? As a result of the volatility in demand and the many other unpredictable 
perturbations that plague supply chains, companies keep significant buffers in the form of inventories. In 
addition to planning, businesses must also be able to adapt to unplanned effects. Such adaptation requires 
flexibility and a means to exploit that flexibility. The present invention exploits the flexibility of trading 
parties to streamline the operations of supply chains by smoothing the boundaries between trading parties. 

The present invention is therefore a system to allow trading parties to express trading desires and con- 
straints across many and varied different factors. These trading preferences are informed by many different 
data sources to optimize for a company's internal operations and its connections to it's supply chain through 
an analysis including total cost factors. The flexibility expressed by all trading parties is exploited to locate 
win- win opportunities for all parties if they exist. 
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4 Summary of the Invention 

We describe the present invention in its application to facilitating trade between buyers and sellers, but 
note that the mechanisms described are much more general. We can easily imagine, for example, using the 
present invention to match individuals (with the desires and skills) to projects. 

The inspiration for the present invention comes from utility theory developed by economists since the 
1960's. Since we are interested in multiple dimensions of negotiation, we draw from the multi-attribute 
utility theory literature. 1 Utility is an abstract concept which has been formalized in various ways. For the 
present purposes utility, w, is a number between 0 and 1 representing a party's willingness to trade. Larger 
values indicate a greater willingness. 

4.1 The Negotiation Space 

In any negotiation the parties must come to agreement on the factors requiring negotiation. We call these 
factors dimensions or variables. As an example, when purchasing a car, the buyer may be concerned with 
price, time of delivery, and color. Each factor price, time, and color is a dimension. Most dimensions can 
be classed as one of three types: continuous, discrete, or range/interval. A continuous dimension is one like 
price for which the buyer's utility varies smoothly across that dimension. The buyer's utility at $23 001.00 is 
almost the same as the utility at $23 000. Color is a discrete dimension. Since the car may only be available 
in black, white, and silver, the domain of this dimension is the finite set of values {black, white, silver}. 
Moreover, the buyer's utility may be quite different for the three colors. The third class of dimensions is 
called interval dimensions. An interval dimension arises often in B2B negotiations. If a machined part is 
built to some tolerance (e.g., the inner diameter of a screw is between 24.5 and 25.5 mm), the range of 
variability in the dimension is specified as an interval. In the language of statistical quality control, a certain 
percentage of the machined parts will fall in this range. These three broad classes of variables capture almost 
all the types of attributes relevant to B2B negotiation. 

The present invention operates over any number of continuous, discrete, and range or interval variables. 
We call the negotiation space X and any point in the negotiation space (x,x,r) G X, It is important to 
recognize that the single trading point (x,*r,r) may have multiple components, e.g., price = $23 000, time 
of delivery = 3 weeks, color = black. 

In the present invention, the space of negotiation is agreed upon by all parties involved prior to the 
commencement of any negotiation. We can, however, imagine more dynamic situations in which dimensions 
are introduced and discarded over time. 

x For a good introduction to multi-attribute utility theory see [1]. 



4 



4.2 The Buyer's Utility Function 

A party defines it's utility function over this space so that every (x,>r, r) is assigned a utility number 
indicating the party's willingness to trade. We indicate the utility function as u((x,^,r)). A great deal 
of work has been done on the appropriate form for utility functions. In the present invention, we take 
a simple form for the utility function for two reasons. First, we would like the form of the utility to 
be conducive to rapid computation. Second we would like the utility to be simple enough to be easily 
understood by and elicited from users of the invention. With no loss in generality, we write the utility 
function as u((x,j*,r)) = exp(— d((x,^,r))) where d(x) is interpreted as the distance of trading point 
(x, r) from the most preferred trade. 

So that we can operate against seller catalogs, only the buyer needs to define a utility function. Across the 
continuous dimensions, the buyer's utility is defined by specifying the most preferred (or ideal) continuous 
dimensions and the manner in which utility drops off as we move away from this ideal. For the discrete 
dimensions, the utility is specified in tabular form since there are a finite number of alternatives. Again, the 
buyer must specify it's ideal discrete values and how utility decays away from those values. In section 6.1 we 
describe how this is accomplished. The range dimensions contribute to utility similarly; the buyer specifies 
an ideal range and the utility decays for ranges other than the ideal according to their distance from the 
ideal. 

The utility function can also express tradeoffs between variables, e.g., I may take delivery in 5 weeks if 
the price drops to $20 000, or I may accept the white car if I can take delivery in 2 weeks. The tradeoffs 
may be between pairs of continuous dimensions (as in the first case), between pairs of discrete variables, or 
between continuous and discrete variables (as in the second case). 

4.2.1 Normalization and Weighting 

When utility is defined over different types of variables, it is important to normalize the contributions of 
each variable so that the buyer can weight the importance of the various contributions to utility. This is 
a difficult problem. How should a buyer's color preferences be normalized so that they can be traded off 
against time of delivery? The present invention solves this problem by requiring that the average distance of 
any negotiation variable from its ideal value is the same for all dimensions. Since the buyer is more interested 
in those regions of the negotiation space where the utility is high, the average is weighted by utility. This 
procedure defines a manner in which to define a baseline where all dimensions contribute equally. Given this 
baseline, the buyer can then weight the various contributions and obtain useful results. 
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4.2.2 Utility Elicit ation 

Since utility is fundamental to the present invention, its elicitation from the buyer is important. Utility may 
be defined using any of a number of sources: 

1. graphical user interfaces associated with the invention 

2. standard benchmark criteria applicable to the domain 

3. formal methodologies like the analytical hierarchical process [2], or discrete choice analysis [3] 

4. inferred through models 

We expand briefly upon method 4. As discussed in the background section, it is important to buyers to 
minimize their total cost of ownership. If we have a function representing these costs as a function of the 
negotiation variables, and perhaps other factors, this function can be used to infer a utility function which 
will act to minimize the total costs. Later we describe how this can be accomplished. 

4.3 A Supplier's Capabilities 

As noted previously, suppliers are treated differently from buyers so that the tool can operate against catalog 
information with no human intervention required on the part of the seller. In fact, we do not require sellers 
to define a utility at all. 

A supplier cannot offer deals at all points within the negotiation space X, e.g., he certainly can't offer 
the black car tomorrow for free! A capability then represents the ability of a supplier to deliver and defines 
a subspace of X. It can include such things as price discounts on large volume orders, variation in delivery 
time as a function of price, etc. Since these relationships are already specified by businesses in terms of 
simple rules like "the price per unit is $10.00 if 1 to 999 units are ordered and $9,50 per unit if 1000 or 
more units are ordered", suppliers' capabilities are represented in the present invention by piecewise linear 
functions. 

4.4 Negotiation Constraints 

Both parties may have constraints which must be satisfied in order for them to trade. For example, the buyer 
may not buy the car unless he gets it within 6 weeks, or he may not purchase the car if it is available only in 
white. These are examples of continuous and discrete constraints, respectively. A continuous constraint sets 
a requirement on the continuous variables. In the present invention, continuous constraints must be either 
linear or quadratic. Discrete constraints involve discrete variables. A discrete constraint can be expressed 
as a list of the allowed (or disallowed) combinations of the discrete variables for which the trade will be 
acceptable. For example, if the buyer would accept either the black or the silver car, the constraint would 
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list both these colors as viable. It is important to note that both continuous and discrete constraints may 
involve one or more variables. We can also express constraints involving both types of variables by allowing 
the continuous constraints to differ depending on the discrete variables. 

4.5 Utility Optimization 

With the major components of the invention in place , we describe how the overall system works. As a 
procurement tool for the buyer, there are two levels of optimization. First, for any given supplier we 
maximize the buyer's utility, subject to the supplier's capabilities to find that trade which makes the buyer 
as happy as possible. Since we are optimizing within a supplier's capabilities, the supplier has expressed a 
willingness to complete the trade at whatever point is determined to be optimal. The tool then optimizes 
across suppliers to rank them according to utility at the optimal point. A graphical user interface allows a 
buyer to investigate the trades suggested by the tool by sorting according to any dimension or by the overall 
utility. 

Utility, while a useful concept in assessing an overall score, may be of limited use to a buyer due to its 
abstract meaning. Consequently, we can also apply the total cost of ownership function to the results to rank 
order the suggested trades according to their various cost components. Recall that for any trade x € AT, the 
total cost of ownership function returns the various cost contributions. This additional information aids the 
buyer in his purchasing decision. The utility number for each trade is still useful because the total cost of 
purchase function includes only those cost factors which can be quantified, whereas the utility also includes 
"softer" qualitative factors. 

4.5.1 Aggregation 

In addition to optimizing against one supplier at a time, the present invention can also be used to optimize 
against an arbitrary aggregation of suppliers. This is important if, for example, no single seller can supply 
the large volume requested by a buyer. In this mode of operation, the buyer specifies sets of suppliers 
participating in the aggregation and the dimensions over which aggregation can occur, and the tool finds 
the optimal combination in which to distribute the volume dimension over the allowed suppliers. 

5 Brief Description of the Figures 

Figure 1 shows an an architecture for the invention. 

Figure 2 shows a schematic of a buyer-specific capability with examples indicating potential input. 
Figure 3 shows a schematic of a supplier-specific preference with examples indicating potential input. 
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n c 


number of continuous dimensions 


rid 


number of discrete dimensions 


n r 


number of range dimensions 


X 


n c - vector of values for continuous dimensions 


3€ 


n^-vector of values for continuous dimensions 


X{ 


value of ith continuous variable 




value of zth discrete variable 



Table 1: Definition of the negotiation search space. 



6 Detailed Description 
6.1 Theory 

In this section we outline the mathematical foundations of the optimization process in sufficient detail to 
allow for computer implement at ion . 

6.1.1 The Negotiation Space 

In Table 1 we define the parameters which collectively define the space of negotiation X. For each of the 
n c continuous variables, we specify an allowed range over which that continuous dimension may vary as 
Xi E Xi — [2Li,Zt], where x is the n c -vector of lower continuous bounds and x is the n c - vector of upper 
continuous bounds. Each discrete variable assumes a value from within its domain >ci G XV Without loss 
of generality, we label the domain of discrete variable i by T> % — [1, • * ■ , d t ] where d % > 0 is an integer giving 
the number of possible values discrete variable >ci may assume. 

With these definitions, we define the space of negotiation by the tensor product X = X\ (g> • - • ® X Uc ® 
£>i O • * • <g> T> Ud . Range variables are treated separately and not negotiated over. 

6.1.2 The Utility Function 

The utility function is a mapping from X into the interval [0,1]. As indicated earlier we assume the utility 
to have the form u(x,*tf) = exp[— d(x, xr)] where d(x,>f) is interpreted as a distance. In what follows we will 
assume that in its simplest form the distance function has the form 

d(x,>f,r) = (x-/i(^))'c- 1 (^)(x-/i(^)) +Z{x) +R(t;x). 

Each contribution to the distance function is positive. We consider each contribution to the distance in turn, 
beginning with the range variable contribution i?(r; x). 
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First, we note that the range distance depends on the setting of the discrete variables. This allows 
the buyer to express different preferences for the range variables depending on discrete factors. The total 
range distance is summed up over all possible range variables so that R(v\ x) = Ya=i ^( r ^ x )* The vector r 
indicates the preferred values for all range variables. If range variable % is specified as the interval r t ~ 
(where > r_d then r is an n r - vector of such tuples. The distance contribution, from one range variable 
will depend on the application. If the range variables are meant to represent the tolerances on machined 
parts where issues of statistical quality control are important, then the distance between two ranges might 
be related to the overlap between Gaussian distributions. If r« is interpreted as a Gaussian having mean 
(Zi + n)/2 and standard deviation proportional to fi — r_i then an appropriate range distance is given in 
Appendix A. Other choices for the range distance function are certainly possible. 

The continuous distance is quadratic and determined by the positive semidefinite n c x n c matrix C _1 . 
We have allowed this matrix to vary with the setting of the discrete variables and indicated this explicitly 
through Q~ x {>c)? The n c -vector fj, may also depend on >c and indicates the point at which the utility is 
maximal - fx is thus identified with the ideal value for the continuous variables. The precise quadratic form 
is convenient, but, using recent developments in interior point methods, other convex functions are also 
computationally tractable [4]. 

The discrete distance is determined through the function Z[yc) which maps the discrete space T>\ (S> - • - ® 
T> nd onto the positive real line [0,oo]. In keeping with the assumption that distance is a function of only 
pairs of components x ti x 3 , we assume the discrete distance has the form 3 

rid rid 
t=l J = 1(t**) 

Each contribution Z ti3 is a table consisting of didj entries, where Z 1 ^{>t l ,>c 3 ) can be interpreted as the 
distance if discrete dimension % has value x % conditioned on discrete dimension j having value x 3 . The 
diagonal terms Z t offer an unconditional distance. The most preferred value for the ith discrete dimension 
is that for which Z z (>Ci) = 0. 

Rather than require the user to enter the distances explicitly, there are numerous ways in which the 
distances can be generated automatically based upon a buyer's ranking of preferred values. Further details 
can be found in Appendix B. 

Weighting of Dimensions 

In many cases it is important for simple modifications of the distance function to re- weight the contributions 
to the total distance. If w c is an n c -vector of weights for the continuous dimensions, we can accomplish this by 
letting C" 1 = W C C _1 W C where W c is the diagonal matrix W c = diag(w c ). 4 In a similar way we modify the 

2 Where no confusion will arise we eliminate the dependence of C" 1 on >c for notational simplicity. 
3 Later we shall generalize this distance to include weighting of dimensions. 

4 M = [rrij^] = diag(v) is the diagonal matrix formed by setting m l}l = v l and = 0 for j ^ z. 
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discrete distance to Z Witi3 mj) = w d; iW d]J Z h:} [p< % , >c 3 ) where is the n^-vector of weights for the discrete 
variables and w d - z is its ith component. The range contribution is also modified so that R w;z {r l ) = w r; iRi(ri) 
where w r is the n r -vector of weights for the range variables and w r -i is its ith component. For convenience the 
weights are normalized so that (l*w c ) 2 + (l £ w ( i) 2 +l < w r = 1. With little additional complexity the dimension 
weights can be made dependent on the setting of the discrete variables but we will assume throughout that 
the weights are constant. 

With these modifications, the total distance function becomes 

d(x,x) - (x-/iM) i C- 1 M(x^M) + Z w {k) +iUr). (i) 

where Z w (x) = ESi ^d ; i{^d;iZi(>Ci) + w d ; jZ t j(>c iJ >c 3 )} and R w (r) = ESi ™r^W 

Assigning weighting factors is useful only if the relevant contributions have been previously normalized 

so that they are all roughly the same magnitude. This serves as the baseline for which all weights are equal. 

The question immediately arises as to what criteria to use to weight the distance contributions. 

We shall determine scaling factors, Q d > 0 and Q r > 0, so that the average distances per dimension of 

the discrete, range, and continuous contributions are equal, where by average we mean a utility- weighted 

average over the entire space of possible trades. This weighting places more emphasis on the better trades 
If d Cj ddi and d r are the continuous, discrete, and range contributions to the total distance, then after 

multiplication by the scaling factors d — d c + Qddd + Q T d T . The scaling factors are determined through the 

utility weighted average distances defined by 

= E^ E r Sy du Qrd r exp[-Q r d r - Q d d d - d c ] ^P[-Qdd d ] Er d r exp[-Q r d r ] J y dxi exp[-d c ] 

~ J2x Er Iv du exp[-Q r d r - Q d d d - d c ] r YL„ e*p[-Q d d d ] Er ex.p[~Q r d r ] J v du exp[-d c ] 

Ex Er Iv du Qddd exp[-Q r d r - Q d d d - d c ] _ Yj* d d exp[-Q d d d ] E r exy[-Q T d r ] J v du exp[-d c ] 
d ~ E* J2rlv du exp[-Q r d r - Q d d d - d c ] d E„ ex.p[-Q d d d ] E r exp[-Q r d r ] J v du exp[-d c ] 

, . = Ex Er Iv dn d c exp[-Q r d r - Q d d d - d c ] _ J2*c ex P[~Qd d d] E r exp[-Q r d r ] J v du d c exp[-d c ] 
~ EvEr Iv du exp[-Q r d r - Q d d d - d c ] exp[-Q d d d ] Er exp[-Q r d r ] J y du exp[-d c ] 

A few comments on the above equations are in order. First, E*e indicates the repeated sum E^ ' " E>r nd 
over all possible discrete trades. Er indicates a sum over all the range variables and the integral over 
volume V indicates integration over the continuous trading volume of interest. Finally, we have not included 
a scaling factor Q c on the continuous distance, since this can be made equal to 1 if we reinterpret Q r as 
Qr/Qc and Q d as Q d /Q c - 5 Each of the averages is an explicit function Q d and Q r . 

The requirement on equal average contributions determines the two unknowns Q r and Q d through the 
equations: (d r )/n r = (d c )/n c and (d d )/n d = (d c )/n c . These two nonlinear equations are coupled in terms 
of Q r and Q d and must be solved simultaneously for Q r and Q d . Further details are found in Appendix C. 
5 We singled the continuous variables out, since there will always be continuous variables in any trading scenario. 
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Table 2: An example set of constraints involving 3 variables where the domains of all variables are T>\ — 
T>2 = T> 3 = {1,2,3}. Constraint (a) requires that the values assumed by >t\, and yc$ are all different 
from each other, and constraint (b) requires that the value assumed by ^ is even. See text for the solution 
to both constraints. 



6.1.3 Constraint Specification 

Buyers and sellers may express constraints over both continuous and discrete variables. 
Continuous Constraints 

For simplicity (and because additional expressiveness is rarely required) we assume that the buyer's con- 
straints over the continuous variables are linear. 6 This allows a buyer to express a constraint, e.g., the time 
of delivery must be within 10 days or I will not trade, i.e., t < 10. We allow for both inequality and equality 
constraints which can be expressed as G^x = and G^x < g^ b \ If there are c[ b ^ equality constraints 
then G^ has rows. Similarly, G^ has c 2 ^ rows if there are inequality constraints. We allow the 
constraints to depend on the setting of the discrete variables, and to be explicit we often write G^(^), 

Discrete Constraints 

We use a standard methodology to represent and process constraints over discrete variables [5] . Abstractly, 
a constraint over a (perhaps proper) 7 subset of the discrete variables is represented as a list of all the allowed 
combinations the variables may assume. An example representation of a pair of discrete constraints is given 
in Table 2. There are two solutions to this set of constraints: >c\ ~ 1, >r 2 = 2, >r 3 = 3 and >c\ — 3, 
H2 = 2, k% = 1. We indicate these solutions as {(^i , 1), (>^2, 2)}, (>f3, 3)}} and {{>q, 3), {>t2; 2)}, {^3, 1)}} 
respectively. Each solution where all the variables have been identified with specific values from their domains 
is called a labelling. 

6 With little additional complexity we can also handle quadratic constraints, see [4]. 
7 A proper subset of a set is the set itself. 
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Computationally efficient representations are used to ensure that only feasible combinations of variables 
are ever processed. Numerous third-party libraries offer constraint programming functionality. 8 

6,1.4 Utility and Total Cost of Ownership 

The buyer's utility function and associated constraints may be difficult for many users to define. In this 
section we show how models of the buyer's business can be used to define utility in a natural manner. 

We imagine a function which provides an estimate of the total cost of ownership for any given purchase. 
Cost contributions to this function might include piece part costs, freight costs, setup costs, quality assurance 
costs, repair costs, etc. It is important to include all quantifiable costs associated with the lifetime of use of 
the purchased product because it is this function we will be minimizing. Significant savings may be obtained 
by taking a longer-term view of the purchase. Revenues (negative costs) generated from the purchase are 
also included in the function so that the function represents some measure of profitability associated with 
the purchase. We write the total cost of ownership function as C 0 (x,x, v\0). We explicitly indicate the 
dependence on the negotiated trade parameters x, and r, as well as other factors 0. The other factors 
might include forecasted demand, current inventory levels, etc. These factors will vary over time, and they 
can be extracted from the buyer's ERP and supply chain management systems (SCM) in real-time just 
before the purchase to ensure continuous real-time optimization. See section 6.2.1 for further details. 

Minimization of C 0 (x, >r, r; 0) defines an ideal trade dependent on current conditions: x op t(/?), ^optOS), 
r opt(/?)- If desired, these can be used to define ft — x opt (/?, r = r opt (0) and the desired ideal discrete 
configuration jc opt (0) (having distance contribution Z = 0). Moreover, the tradeoffs between continuous 
dimensions around this minimum can be obtained through calculation of the Hessian matrix H = [K^] 
where the i, j matrix element is given by 

dx t dx d x=Xopt ^ ^„ opt (j8) )r=ropt (j£3) 

We then identify C _1 with H. In this way, little trading flexibility is obtained in directions where total cost 
of ownership rises rapidly, while significant flexibility is obtained in directions where total cost of ownership 
increases slowly. 

In summary, a total cost of ownership model defines both the most preferred trade parameters and the 
flexibility possessed around the preferred trade. The model pulls dynamically from real-time data sources to 
provide the most up-to-date optimization based on total costs of ownership and other important qualitative 
factors the buyer may wish to describe in the utility function. The same function and its constituent costs 
may also be used to help analyze proposed trades from suppliers. 
8 See for example www.mozart-oz.org or www.ilog.com. 
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6.1.5 Supplier Capabilities 

As discussed in the introduction, suppliers represent their capabilities through a specification of the subspace 
of X in which they will trade. A supplier's capabilities must specify the allowed continuous, discrete, and 
range variables. The allowed range variables are expressed as the pairs (r^r^), one for each range variable. 
For example, if a supplier produces 25mm inner diameter screws to within a tolerance of 0.5 mm, then the 
range variable is simply (24.5, 25.5). These are compared with the buyer's ideal range and contribute to the 
distance function through the R^(^) function. 

Capabilities over continuous and discrete variables are more complex. 

Continuous Capabilities 

Continuous capabilities are viewed naturally as responses to a buyer's request. Thus we distinguish between a 
buyer's requested continuous vector and a seller's response x( s ) . A vector- valued function, f (x^ , x( s ) , *c) 
returns the response based on the buyer's request and also, perhaps, other previously defined supplier 
responses. Component fi of f defines the ith continuous variable, i.e. x[ s ^ — /i(x^,x^). 

Currently, suppliers are used to quoting price discounts for large volume orders and these price discounts 
are expressed as piecewise linear functions. Consequently, we restrict fi to have the following form (where 
we distinguish between the functions depending on the buyer and seller variables): 

k 

An example of how this may be used to define a supplier response is the following: We assume three 
continuous dimensions - price, volume, and time of delivery and indicate these as [xi , £2, ^3] = [p» v , t]. Then 
a response may be formed as 

„(»> = /„><»>) 

« (,) =/i(« (,) ,t (6) )=/t,»(w w ) 

p {s) = /p(« (s) ,* w ) = f P M s) ) + f P At {s) )- 

The f V)V function returns the volume a supplier will fulfill as a function of what the buyer asked for. If the 
supplier can deliver any volume, this will be the identity function. If the supplier delivers only in certain lot 
sizes, this function may have a staircase shape, etc. The ft iV function indicates the time it will take a supplier 
to deliver a certain volume. So, for example, if larger shipments require longer transportation, then this 
dependence is given by this function. Finally, we turn to the price determination. In this example the price 
depends on the quantity being shipped and the f PfV might represent price discounts for large volume 
orders. There is also an incremental price contribution based on the time of delivery. If faster delivery is 
more expensive, this is reflected in f p j. 
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For a given setting of the discrete variables, each f^ s k \x k s \t<^) and f^ b k \x k b \»<^)is a one-dimensional 
piecewise linear function. Consequently, the functions can be specified by listing the breakpoints. If 
4l ) (4 s) .^ (s) ) has «$ breakpoints, then we list these as {x[ s) {b\" ] k - I) , x[ s) (b[ s } = 2), • • • , sjj.* 5 - 
^l)Y and function values at these breakpoints are {/<J (*<*> (&« = I)) (b^ k = 2)) , ■ ■ ■ , (x^^ 

K i $ k)) } • Similarly, , is a piecewise linear function defined by the k^I breakpoints {x^ (b\ b l = 1) , x^ (b^l — 

2).'- - = and function values at these breakpoints = l))./^^^ = 

2)), • • • j (x^ (b[ b l = ftffe)) }• The breakpoints are indexed by the integers b^l and bf\. 

An interval is specified by assigning a value b^l £ — 1] and bfl € [1, «^ - 1] so that 10 

4 S) 0$) < 4*' < 4 S) (#2 + 1) V i and xf (&$) < x[ 6 ' < x<« (6$ + 1) V i. (3) 

Within each interval the functions are linear, so we have 

*<•> = «(*«,{&«}, {bfl)) + J2 m %&'\b$)xP + m«(fc<S)*£ 6> 

k 

where c$(v(*\ {b^l}) = c s*fc(^ s ^ ^fc)^ 0 ^^^)- ^ n the above equations, the intercepts and slopes 

are given explicitly by 

is)fh (s h _ 4 S) (&S + (4 S) M) - 4 S) (hk)f$ (4 S) + 1)) 

and 

(S ),( S ), _ /i; fc ) (4 s) (^+i))-4i ) (4 s) (^)) 
4 s) (^ + d-4 s) (^) 

respectively. An analogous result holds for the cfl(bfl) and m^l^b^l). 

(s) (s) (s) 

To eliminate any cyclic dependence on we must impose an ordering on so that x\ can only 
(*) 



depend on } where j < i. Consequently, we can write 



*W = ^) {ftW,- • • ,%U}, {b%}) + £rn$(" (5) >04 S) + E-SC)4 6: 



k<% 

Written as a matrix equation, the above becomes 



(I - M<- {^i}))x Cs) = c(xW, {&$}) + M^({6$})x 



(&) 



n c I j 



where c(^),{bg},{^}) = [c^M^ HQ) ••- *,(*<•>, {^})f> * W = [4 S) - *£? 

9 The breakpoints are assumed to be in increasing order. 

10 Note that many choices for {fc^} or {b[ b ^} would be inconsistent with these constraints. A simple way to fix this is to 
define a union of all breakpoints (s) and (6), and have all fi t k have the same breakpoints. 
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A") 



.(») 



and 



M W (^,{^}) = 



0 



0 
0 



0 
0 
0 

<(»> fc<»> 



and 



M< 6 > ({&$}) = 



In most cases x (5) will depend only on a subset of the variables in x w . If x c *) depends on n f < n of the 
variables, then M c&) is an n x n f matrix. In the example given everything depending only upon the volume 
the buyer requested. 

Since M^(^( 5 )) is lower triangular and can be inverted in time 0(n), we can rapidly express as 

X W = (I-M«(*M,{^^ (4) 

as long as the b^J are chosen to also satisfy x[ s \b^l) < < x^\b^l + 1). These constraints will be used 
in section 6.1.6 which formulates the optimization problem. 

We also allow a supplier to express additional linear constraints so that, for example, he may represent 
that he does not deliver on Sunday. Thus the supplier may define the matrices G^ s) (», G^ 8 \k), and the 
vectors gj a) (x), g< a) (x) such that G^x( s ) = g[ s) and G^x^x < g<*>. G<* } (x) and G^fx) have c[ s) and 

(s) 

c\ } rows respectively. 
Discrete Capabilities 

It is easy to imagine that a supplier's response on a discrete dimension is highly constrained by the values 
of the response on other dimensions, e.g., certain product characteristics come only in certain colors and 
package sizes. Consequently, it is not suitable to explicitly define a response but only to make available 
a supplier's constraints amongst the discrete variables. Consider 3 discrete dimensions where >c\ € 2>i = 
[a,&,c]j x 2 € D 2 = [A,B,C,D], and x 3 e V 3 = [a,/?,7, £], and assume the supplier has the following 3 
constraints 

Ci (*i , x 3 ) - {(a, a) , (a, /?), (6, /?) , (c, /?)} , 
C 2 (x 2) X3) = {(A ) iS),(B,7) s (AiS)} ) 
C3O1) - {b,c}. 



m (&) (b (b) ) 
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We first note that there are 4 feasible solutions (or product configurations the supplier can meet): \>c\ , >t<z , ^3] = 
[b,A,P], [b,D,f3], [c,A,j3], or [c,D,/3]. Feasible solutions to the constraints define the response for the 
discrete variables. 

We indicate a supplier's or buyer's collective set of discrete constraints by (>c) and (>c) respectively. 



6.1.6 The Optimization Problem 

Having defined the necessary components, we now define the optimization task which determines the con- 
tinuous x* and discrete parameters of the trade. 

Since the trade must be acceptable to the supplier, we maximize the buyer's utility over a supplier's 
capabilities. Equivalently, we minimize the distance from the buyer's ideal values as 

[x*,x*] = arg min {(x« - /i^))^" 1 ^) (x« - li{x {s) )) + Q d Z w (x {s) ) + QrRwW] 



where 



x ( s ) = (I-M«(x< tf >)) _1 c(x<*>) + (I-MW^Wj^M^xW 

subject to the constraints over continuous variables 

GM S) )* (S) = gi(" W ), G 2 (jfW)xW < g 2 (~ (s) ) 

and the constraints over the discrete variables C^(v^), C^(v^). In the above, we have denned the 
(c[ s) + c[ b) ) x n c and (c 2 s) + cf ] ) x n c matrices Gi(*W) and G 2 (>f (s) ) by 



Gi(xW) = 



G[ w (x«) 



and G 2 (*r (s) ) = 



G<V>) 



, and g 2 (^ (s) ) = 



g<'>(*«) 
gl 6) (x<' ) ) 



The (c^° + cf')- and (c^ } + cf ^-vectors gi(* (s) ) and g 2 0 (s) ) are denned by 

|_g^V {s) ) 

The optimization is accomplished by iterating two distinct phases. Phase one sets the continuous param- 
eters optimally for a given setting of the discrete variables. We define the functions 

<*i(x,x) - (x-//(^)) t C- 1 (^))(x-p(^)) +R{v;x) and d 2 {>c) = Q d Z w (x {s) ), 

The first phase of the optimization is the continuous problem: 11 

x*(>r) = arg min di{x^ 8 \x) subject to Gi(^)x = giM and G2MX < g2(**)- (5) 



11 No optimization is required over range variables, since these are specified up front by both buyer and seller and merely add 
to the total distance. 
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A detailed discussion on the solution of the phase 1 optimization problem is found in appendix D. The 
second phase determines the best value of the discrete variables by minimizing over a function of m alone 

= arg min di(x(x),x) + d 2 {x) subject to C (6) (x) A C (s) O). (6) 

Further details on the phase 2 optimization are given in Appendix E. Once ^* has been determined, we find 
x* as x* — x(x*). 

6,1.7 Aggregation 

Often a buyer may be willing to divide an order between multiple suppliers in order to aggregate the required 
demand or to obtain better deals. In this section, we detail how the present invention supports this aggregate 
optimization. 

Aggregation can only occur over the continuous variables where values may be subdivided. Each contin- 
uous variable Xi must be parcelled out amongst a set of suppliers. Consequently, we extend our notation to 
%i — > £i, k giving the contribution of the kth supplier to continuous dimension i. The kih supplier may come 
from a (perhaps proper) subset of all suppliers. We indicate the set of potentially contributing suppliers as 
JC and the number of potentially contributing suppliers as |^C|. 12 

We restrict the discrete variables to be the same across all potentially aggregated suppliers, i.e., we do 
not generalize >c % -» This simplifying assumption is made for two reasons. First, the size of the discrete 
optimization problem is smaller and so optimization be performed faster. Second, it may be difficult to 
elicit from the buyer the allowed discrete alternatives for each supplier. Nevertheless, this generalization is 
straightforward should the need arise. 

This simplifying assumption requires that the union of discrete supplier constraints Cjcfe) = AfceJC ^k^fe) 
yields a feasible solution when combined with the buyer's discrete constraints C^ h \>c). A necessary (but not 
sufficient) condition for satisfaction is then that each constraint satisfaction problem k having constraints 

{j€)AC^ {>c) has a feasible solution. 13 Henceforth, we will assume that the set of suppliers, JC : satisfies this 
condition. If not, those suppliers violating the constraints C^{>c) AC^(x) are eliminated from consideration 
in JC. 

Discrete Search 

We must search over the subsets of JC for feasible solutions, which is a combinatorial problem. Fortunately, 
given a complete labelling of variables, determining the largest subset is easy. For any given labelling of all 
discrete variables, if each C (6) AC { k s) V k e k C JC is satisfiable, then the union C (6) ACi s) where C { K s) = f\ k ^ K C { k s) 
is also satisfiable under the same labelling. The largest subset of variables is found by adding all k which 
12 All work to this point is thus seen as the special case \K\ — 1. 

13 It is easily seen this requirement is not sufficient by having = 1), 2)}, c[ s ^ = {{xi , 1)}, and ~ {(^i,2)}. 
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have feasible solutions with the buyer. We needn't worry about smaller subsets because the continuous 
optimization will assign zero values to those if appropriate. Consequently, for any given labelling x we let 
/C(x) represent the maximal subset of suppliers for which C^ b \>c) A Cjc{>e) is satisfiable. It is this set of 
suppliers which enter into the continuous optimization. The number of participating suppliers is denoted by 
|JC(*)|. 

Continuous Optimization 

Optimization over the continuous variables is carried for each labelling xr. Generally speaking, the buyer's 
utility will not be an explicit function of x t] k but only of x % . We assume a linear relationship between these 
two quantities so that 14 

x = Ex. 

The u c \K{h)\ vector x is defined as x* = [xi, ■ • • ,x n J where x* = [x~i-i, * • • , £i ; |jc(>r)|]- The n c x ti c \]C{k)\ 
matrix 3 is assumed known and typically has the form 15 

o £ i\ ... 0* 

where 0 is the K- vector of all zeros and & is the linear combination relating x z to the £ 2; fc. Under our 
assumptions for H, Xi = £*x$. In cases where the buyer wants to accumulate the results from suppliers (e.g., 
aggregating quantities) £ = 1 is the |/C(x)| -vector of all Is. In other cases the buyer may take £ = 1/\JC(j<)\ 
so that the time of delivery becomes the average time of delivery across the suppliers. Constraints on x 
become constraints on x via 

G-! (x )x = gi (x) and G 2 (>tr)x < g 2 {*) (7) 

where Gi(V) = Gi(^r)H and Gi(jtf) = Gj(>f)S. We might also expect the buyer to add additional linear 
constraints, such as requiring the latest shipment from any supplier to arrive earlier than a certain date, or 
requiring all deliveries to arrive the same day. There can also be constraints specific to particular suppliers, 
e.g., the buyer doesn't want any more than 100 units from supplier 5. These can be handled simply as 
constraints on the individual Xi-k and added as extra rows to Gi(>r), G 2 M, gi(j*), and g2(>0- 

With aggregation, the quadratic form to be minimized is (Hx — ^(^))*C~ 1 (>^) (Sx-/i(x)) subject to the 
constraints given in Eq. (7) . This minimization can be carried out through a straightforward generalization 
of the method given in Appendix D. 

14 We can also relate x and x by x = Sx + v for some constant vector v, which will not cause any complications. However, 

there seems to be little practical reason to do so. 

15 With no additional computational complexity, we can allow E to depend on >c. 
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6*2 Implementation 

In this section we outline an implementation of the entire e-procurement invention. We begin with a high- 
level description of the architecture, then fill in the details by describing a complete object model. 

6.2.1 High-level Architecture of the Invention 

There are at least two modes in which the invention may be used. First, the invention may reside at the 
site of large buyers, and suppliers who wish to sell to the buyer may be required to submit their capabilities 
via a web interface to the buyer. The invention may also be used within a marketplace hosted by a third 
party. Buyers /sellers log onto the market, submit their preference/ capabilities, and act on the results. The 
architecture is modular enough to support both modes of operation. 

In Figure 1 we present an architecture for the invention. We describe the architecture, starting from the 
optimization algorithm which finds matches between buyers and sellers and work our way outwards. 

A controller surrounds the optimization engine, feeding it buyer preferences and seller capabilities. If 
multiple optimization processes are running (perhaps on different machines), the controller can also do 
load balancing, forwarding the request to the least busy process. The controller decomposes preferences 
and capabilities into their constituent buyer- and seller-specific versions (see below), selects the most specific 
matching preference/capability pairs, and sends them to the matching engine for optimization. The controller 
then collects responses from the matching engine and returns them to the buyer. Additionally, the controller 
logs all results into a database for recording purposes. 

Another layer, called the Connector in Figure 1, separates the graphical user interface (GUI) through 
which users communicate with the tool from the controller. This layer serves a number of functions. The 
connector transforms the description of preferences and capabilities from the GUI into a form suitable for the 
implementation of the matching engine. Part of this transformation involves validation of appropriate input 
from the GUI layer so that no malformed input is ever sent to the controller. The Connector layer can also 
pull data from ERP or SCM systems and automatically infer preferences (using the total cost of ownership 
function) for the buyer. The enterprise abstraction layer insulates the Connector from the precise details of 
the manner in which the ERP and SCM data needs to be gathered. Total cost of ownership is evaluated in 
the simulation modules, which may either be running locally at the client's site or running centrally at the 
main server. These simulation modules pull operational data (the vector /?)from the enterprise abstraction 
layer. A preference optimization module (TCO) minimizes the total cost of ownership to determine the ideal 
trade and the flexibilities around the ideal trade. 

At the outmost level, a layer provides integration with the GUI and/or host system. A number of 
administrative systems are expected at this layer. Market administration services allow easy definition 
of trading spaces, the dimensions of negotiation, limits on continuous variables, allowed settings of the 
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discrete variables, etc. User administration services allow an administrator to define buyers, passwords, 
spending limits, etc. Supplier services accomplish similar tasks on the supply side. Managers for preferences, 
capabilities, and match results ensure that these objects are properly stored in a database. This layer layer 
also dynamically generates the html necessary for presentation of the data via a web interface to buyers and 
sellers. 

For maximal portability, communications between the View and Connector are via XML documents. For 
maximal efficiency, communications between the Connector and matching controller are as serialized Java 
objects. 

6.2.2 An Object Model for the Invention 

The fundamental objects required for the invention are preferences from buyers, capabilities from sellers, and 
match results returned to all parties. The components of such objects have already been considered from a 
mathematical point of view, and we now describe one possible computer representation. 

In this section we describe a complete grammar for the object model. The following syntactic conventions 
are used: 

• (nt) denotes a non- terminal symbol nt 

• [obj] denotes an optional grammar segment obj 

• {obj} denotes 1, or many times the grammar segment obj 

• — > denotes a production rule for non-terminal symbol. If there are multiple rules, say (a), (b), and (c), 
then these are denoted as 

<nt> -» (a)\(b)\{c). 

In contrast, a production rule of the form 

(nt) ->(o> ,<&),(<:> 

indicates that the non-terminal (nt) is composed of three grammar segments, (a), (b), and (c) 

• terminal keywords are in serif font 

Obvious non-terminal grammar elements like (string) and (integer) are not described. 
Supply Side 

To represent capabilities that apply to a specific buyer (perhaps for contractual reasons), we have defined a 
capability to be a list of (buyer Specific Capability). With one exception, a buyer-specific capability applies 
only to one buyer - that buyer associated in the id field of the (buyerSpecificCapability). The exception 
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occurs if the id field is * or wildcard. This indicates that the capability applies to all buyers. Using 
buyer-specific capabilities, suppliers can represent specific capabilities to certain buyers and generic capa- 
bilities applying to all other buyers. By not including a wildcard {buyerSpecificCapability} and only listing 
(buyerSpecificCapability) s applicable to specific buyers, sellers can also represent the fact that they will 
trade only with a subset of all buyers. In cases where both the wildcard (buyerSpecificCapability) and a 
(buyerSpecificCapability) applicable to a specific buyer apply, the most specific (buyerSpecificCapability) is 
selected. 

A schematic of a ( seller SpeciflcP reference) is given in Figure 2. 
We begin at the top level of a capability: 

capability — > {(buyerSpecificCapability)} 

where 

(buyerSpecificCapability) — > id: (id), 

d iscrete: {( discrete VarDescript ion) } , 
continuous: { (continuous VarDescription)}, 
range: {(range VarDescript ion)}, 
[discreteConstraint: (discreteConstraint)], 
i nsta n ce : { (discreteCapabilitylnstance) } 
[aggregationParticipation: 0|1], 

(id) identifies a buyer or group of buyers. Individual buyers are represented by some unique identifier (say 
an integer) and the group of all buyers is identified by the wildcard character So we have 

(id) — > (integer) | * . 

aggregationParticipation is a Boolean flag giving the supplier's willingness to participate in aggregate orders 
to the identified buyer. 

Each of the variable constituent components is described by 

(discrete VarDescription) -> name: (integer), 

a I lowed Values: {(integer)} 

(continuous VarDescription) — » name: (integer), 

min: (double), 

max: (double) 
(range VarDescription) — > name: (integer).. 
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In its simplest form, a (discreteConstraint) is a list of more primitive constraints 

(discrete Constraint) — > {(primitiveDiscreteConstraint)} 

where each primitive constraint is composed as follows: 

(primitiveDiscreteConstraint) -> name: (string) 

variables: {(discreteVarName)}, 

includes: 0 1 1, 

values: (integerMatrix) 

(discreteVarName) is the name of the discrete variable involved in the constraint 

(discreteVarName) — » (integer). 

The includes field is a bit. If the bit is 1, then the combinations listed in the values field are the allowed 
values the variables may take on. If the bit is 0, then the combinations listed in values are the excluded 
combinations, i.e., everything in the powerset of the variables is allowed except those combinations listed in 
values. The order of the variable names is significant, since they will be assumed to be in the same order in 
values. If there are a variables involved in the constraint, and c constraints, then (integerMatrix) is an a x c 
matrix of integers: 

(integerMatrix) (integerVector) , ■ • • , (integer Vector) 
(integer Vector) — > (integer) , • * • , (integer) 

The (discreteCapabilitylnstance) component is described by 

(discreteCap ability Instance) — > mask: (discreteVarMask), 

[rangeCapability: { (range Varlnstance)}], 
continuousCapability: (continuousCapability) 
continuousConstraints: (continuous Constraints) 

A (range Varlnstance) defines a range variable and has the form 

(range Varlnstance) — > name: (integer), 
min: (double), 
max: (double). 

The (discreteVarMask) relates to the discussion of 6.2.2. As in Table 3 we have 

(discreteVarMask) { (extended Var Value)} 
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where an (extendedVar Value) is either an integer from the domain of the discrete variable or the wildcard 
character 

(extendedVar Value) (integer) | * . 

(continuousConstraints) describes the hard linear constraints for the continuous variables. Since these con- 
straints may be either inequality or equality, we have 

(continuousConstraints) [equality: (linearConstraints)], 

[inequality: (linearConstraints)] 

Both the equality and inequality constraints are expressed through a matrix which is c x n c where c is the 
number of constraints, and a vector which is c x 1. Consequently we have 

(linearConstraints) -> matrix: (doubleMatrix), 
vector: (double Vector) 

A (doubleMatrix) is defined by 

(doubleMatrix) ( double Vect or ) , • • • , (double Vector) 

and a (double Vector) is just what the name suggests - a vector of doubles: 

(double Vector) -» (double),-- - , (double). 

The only remaining undescribed element above is (continuous Capability) whose description is 

(continuousCapability) — > breakpoints: (doubleListMatrix) , 

va I At B rea k Po i n ts : (doubleListMatrix) 

(doubleListMatrix) describes a n c x n c matrix whose elements are lists of (double): 

(doubleListMatrix) -> (doubleList Vector) , ■ • • , (doubleList Vector) 
(doubleList Vector) (doubleList) , * - - , (doubleList) 
(doubleList) -^{(double)} 

It is assumed that the rows and columns of the matrix are in some canonical order so that we know which 
continuous variable is referenced. A natural order is the one defined in { (continuous VarDescription)} 

Preferences 

Just as capabilities may be buyer-specific so too may preferences be seller-specific. The same rules deter- 
mining which seller-specific preference to apply are followed. A schematic of a (sellerSpecificPreference) is 
given in Figure 3. 
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We define a preference as follows 

(preference) — > {{sellerSpecificPreference)}[, (aggregatedP reference)] 

i.e., a preference is a list of (sellerSpecificPreference) with an optional aggregated preference. We first 
describe (sellerSpecificPreference) and then consider (aggregatedPreference) . 
The (sellerSpecificPreference) is composed as follows 

(sellerSpecificPreference) -^-id: (id), 

discrete: { (discreteVarDescription) } , 
continuous: { (continuous VarDescription)}, 
range: {(range VarDescription)}, 
di me nsion Weights: (dimension Weights) , 
discreteTradeoff: (tradeofTTables) 
[discreteConstraint: (discreteConstraint)] , 
i nsta nee: { (discretePreferencelnst ance) } 

Of these elements, only ( dimension Weight s) , (tradeofTTables), and (discretePreferencelnstance) have yet to 
be defined, (dimension Weights) gives the weights of all dimensions that indicate their importance. For 
convenience we break up the weights according to the three types of variables. Thus we have 

(dimension Weights) — > range: (double Vector) , 

discrete: (double Vector) , 
continuous: (double Vector) 

A (double Vector) has been described previously. Each of the corresponding vectors is as long as the number of 
range, discrete, or continuous dimensions. (tradeofTTables) is an n^screte xndiscrete matrix of (tradeoffTable) : 

(tradeofTTables) -> (tradeofTTableMatrix) 
(tradeofTTableMatrix) -» (tradeoffTable Vector) , • • • , (tradeoffTable Vector) 
(tradeoffTableVector) (tradeoffTable), • • ■ , (tradeoffTable) 

A (tradeoffTable) is simply a matrix of double values. 

Finally, we turn to the last undefined component of a (preference). A (discretePreferencelnstance) is 
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composed as follows: 

(discretePreferencelnstance) —> mask: (mask), 

[ra n gel deal . { (rangeVarlnstance)] , 
continuousldeal: (double Vector) , 
tradeofTMatrix: (doubleMatrix), 
[continuousConstraints: (continuous Constraints)] 

The rangeldeal and continuousldeal fields give the desired range and continuous trade parameters. The trade- 
ofFMatrix field gives the positive definite matrix expressing the tradeoffs amongst the continuous variables. 
(continuousConstraints) have been described previously in the sell-side specification. 

To complete the specification of preferences, we conclude with the definition of (aggregatedPreference). 
Refer to the discussion of section 6.1.7 for details. 

(aggregatedPreference) — > participants: {(aggSpecification)}, 

contributionType: (contributionTypeVector) , 
additionalConstraints: (continuousConstraints) , 
discrete: { (discrete VarDescription) }, 
continuous: {(continuous VarDescription) } , 
range: {(range VarDescription)}, 
dimensionWeights: (dimension Weights), 
discreteTradeoff: (tradeoffTables) 
[discreteConstraint: (discreteConstraint)], 
i n st a nee: { (discretePreferencelnstance) } 

In the above definition, the previously defined elements maintain their meaning. The additionalConstraints 
field allows the buyer to express constraints around the aggregation, such as "all orders must arrive on the 
same day," etc. participants lists the suppliers who can participate in the aggregation and their characteristics. 
Note that if the wildcard supplier participates, the order can potentially be aggregated across all suppliers. 
(aggSpecification) describes information specific to a supplier participating in the aggregation. It is defined 
by 

(aggSpecification) id: (id). 

id identifies the participating supplier and constraints specific to that supplier defined in an accompanying 
(sellerSpecificPreference) will be used in the optimization. Additional information may be added as required. 



25 



discrete mask 



output 



specificity 




{continuous 1, range 1} 
{continuous2, range2} 
{continuous3, range3} 



0 



1 



2 



Table 3: Example of discrete masks for specifying continuous and range variables which are dependent on 
discrete variables. >c x and >r 3 signify specific values for the first and third discrete variables. The specificity 
of each mask is indicated in the third column. 

The contributionType field is used to define the £ vectors used in aggregation. The (contributionType Vector) 
consists of n c elements indicating the type of aggregation for each continuous dimension: 

(contributionTypeVector) -> (contributionType) , ■ , (contributionType). 
Possible contribution types include 



sum sets f = 1, average sets £ = and zero sets £ — 0. 

Masking 

We have allowed constraints, ideal values, tradeoffs, and continuous capabilities to be dependent on discrete 
variables. In this section we describe an efficient manner in which to encode this dependence. 

The data structure must represent continuous and range variables for all valid discrete inputs. An 
efficient way to do this is to use hierarchical definitions. At the top of the hierarchy are the definitions 
of the continuous and range variables for the discrete values k 1 = [*,••• , *]. These values apply to all v 
unless more specialized masks are defined. A more specialized mask of the continuous and range variables is 
specified by defining values for some of the components yc % . The more components that are defined, the more 
specialized the definition. The most specific mask is always used. An example definition for three discrete 
variables is given in Table 3. The response to the lookup ^3] is {continuous3, range3} if and only 

if Hl = k x A JK3 = 5f 3) {continuous2, range2} if and only if >ti = $t x A xr 3 ^ £3, and {continuous]., rangel} 
otherwise. 

Match Results 

Returned to the buyer is a list of matches with different suppliers, which can be ranked and viewed in many 
different ways in the GUI. A (matchResultList) is a list of matchResult: 



(contributionType) sum, average, zero. 



(matchResultList) {(matchResult)}. 
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A match result may either be a (singleSupplierMatchResult) or an (aggregatedMatchResult): 

(matchResult) -> (singleSupplierMatchResult) | (aggregatedMatchResult) . 

A (singleSupplierMatchResult) represents the best trade with a single supplier and is composed of the 
following elements: 

(singleSupplierMatchResult) -» supplierld: (integer), 

utility: (double), 
feasible: 0|1, 
[costFactors: {(double)], 
continuous: {(double)}, 
discrete: { (discreteVarDescription) } , 
range: (range Varlnstance) . 

The supplierld indicates the supplier sourcing this trade and the utility field indicates the utility of the trade 
(which can be used to rank the trades), feasible is a bit indicating whether or not a feasible trade with this 
supplier was found. The continuous, discrete, and range fields list the respective trade parameters determined 
by the matching algorithm. The optional cost factors field lists the constituent costs contributing to the 
total cost of ownership C Q evaluated at the trade point returned in the (singleSupplierMatchResult). 

An (aggregatedMatchResult) returns the optimal trade when the buyer has requested aggregation. It is 
composed of the following elements: 

(aggregatedMatchResult) — >• utility: (double), 

feasible: 0|1, 
[costFactors: {(double)], 

suppIierTradeParameters: { (supplierTradeParameters) } . 

As before, the utility field gives the utility of the aggregate trade, and the feasibility flag indicates whether or 
not a feasible aggregate trade was found (there may not be if the constraints were too stringent). costFactors 
can also be returned in C 0 is sufficiently general to handle aggregated trades. Finally, (supplierTradeParameters) 
lists the trade parameters for each supplier involved in the aggregation. It is defined as follows: 

(supplierTradeParameters) -» supplierld {integer), 

continuous: {(double)}, 

d iscrete: { (discreteVarDescription) } , 

range: (range Varlnstance). 
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6,3 Summary 

We have described an efficient computational procedure in which to encode buyer's trading preferences 
and hard constraints, supplier's delivery capabilities and constraints, and optimize to find those matches 
between one buyer and one or many sellers that maximize the buyer's utility. By optimizing against both 
qualitative and quantitative factors, and exploiting the trading flexibilities possessed by both parties, the 
system determines better trades. The tool is particularly useful as companies move their direct material 
purchasing online. By optimizing across flexibilities, win- win trades are discovered for both trading parties. 

The representation of trading preferences is designed to be expressive yet easily elicitable from a buyer, 
and computationally tractable. The representation of supplier capabilities was chosen to parallel the manner 
in which suppliers already think of their delivery capabilities and seamlessly includes volume discounts and 
incremental costs. These supplier capabilities may be part of an online catalog. The representation of the 
negotiation space is rich, supporting three types of variables. 

We have outlined a manner in which preferences may be inferred automatically through models of the 
purchasing company. Such models incorporate many cost factors, taking the total cost of ownership into 
account. The system provides trades which minimize the total cost and represent significant new savings. 

The invention can operate both at a buyer's site, where suppliers input their capabilities through an 
HTML interface to the world wide web or as an embedded part of an electronic market hosted by a particular 
web site. The invention may operate at regularly scheduled intervals or sporadically in lieu of current request 
for quotations (RFQ). The buyer may broadcast a RFQ event to suppliers, indicating a time within which 
suppliers must respond. At the close of the event, the buyer can use the present invention to assist in the 
analysis of the supplier responses. 

Complex algorithms have been specified which should permit most matching optimization to occur in 
near real-time. The rapidity of optimization, combined with graphical what-if tools, allows for analysis and 
exploration of trades, which should significantly improve the quality of purchasing decisions. 

While the above invention has been described with reference to certain preferred embodiments, the scope 
of the present invention is not limited to these embodiments. One skilled in the art may find variations of 
these preferred embodiments which, nevertheless, fall within the spirit of the present invention, whose scope 
is defined by the claims set forth below. 
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